home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / cip / cip-minutes-89july.txt < prev    next >
Text File  |  1993-02-17  |  8KB  |  208 lines
  1. ST and Connection IP Working Group
  2. Chairperson:  Claudio Topolcic/BBN
  3.  
  4.  
  5. CURRENT MEETING REPORT
  6. Reported by Steve Casner, Allison Mankin and Claudio Topolcic
  7.  
  8.  
  9. ATTENDEES
  10.  
  11.  
  12.        1. Casner, Steve/casner@isi.edu
  13.  
  14.        2. Clark, David/ddc@lcs.mit.edu
  15.  
  16.        3. Fedor, Mark/fedor@nisc.nyser.net
  17.  
  18.        4. Fox, Richard/rfox@suntan.tandem.com
  19.  
  20.        5. Mankin, Allison/mankin@gateway.mitre.org
  21.  
  22.        6. Mazraani, Tony/tonym@flora.wustl.edu
  23.  
  24.        7. Park, Philippe/ppark@bbn.com
  25.  
  26.        8. Parulkar, Guru/guru@flora.wustl.edu
  27.  
  28.        9. Ramakrishnan, KK/rama@erlang.dec.com
  29.  
  30.       10. Su, Zaw-Sing/zsu@sri.com
  31.  
  32.       11. Toplocic, Claudio/topolcic@bbn.com
  33.  
  34.       12. Wood, C. Philip/cpw@lanl.gov
  35.  
  36.       13. Zhang, Lixia/lixia@lcs.mit.edu
  37.  
  38.  
  39. MINUTES
  40.  
  41. The working group held three meetings.  The meeting held during the day of
  42. Tuesday 25 July covered the high level and long term issues of connection
  43. oriented internet protocols.  A second meeting was held on 26 July and
  44. covered a number of short term issues that need to be discussed to finalize
  45. the ST specification.  Since all such issues hadn't been addressed, we held
  46. a third meeting during the morning of 27 July.
  47.  
  48. Connection_oriented_internet_protocol_meeting_of_25_July_1989____
  49.  
  50. Three presentations were made.  Lixia Zhang described the Flow Protocol
  51. (FP). Guru Parulkar gave a high level description of McHIP and Tony Mazraani
  52.  
  53. described the McHIP protocol in more detail.  These interactive
  54. presentations took the bulk of the day.  Their content is not described here
  55.  
  56. because they are better described in other documents.
  57.  
  58. The suggestion that the working group adopt McHIP as its protocol led to a
  59. discussion about the future of McHIP, ST and the working group.  Adopting a
  60. specific protocol would provide direction and structure.  It would help keep
  61. the working group from endless debating.  It would cause us to look at
  62. practical tradeoffs, etc.
  63.  
  64. If a protocol is to be selected, then what should it be?  The three choices
  65. appear to be McHIP, FP, and ST-2.  It is somewhat easier to consider the
  66. relation between McHIP and ST-2.  It would be optimal for both to evolve to
  67. a single protocol.  This is reasonable since they are very similar.  A
  68. significant difference is that ST-2 uses simplex connections to support
  69. conferences and McHIP uses omniplex connections.  Another issue is that ST-2
  70. is a very short term effort that will be operational in approximately six
  71. months, whereas McHIP is being developed in a somewhat longer schedule.
  72.  
  73. McHIP is harder to compare with FP. They seem to be addressing different
  74. issues.  Guru felt that FP is more a network protocol than an internet
  75. protocol because it does not fully address the use of pure connectionless
  76. networks.  Claudio felt that McHIP addresses a number of protocol issues,
  77. while FP provides a resource management algorithm.  Claudio felt that we
  78. could reasonably implement a version of McHIP that incorporates an FP style
  79. resource management scheme.
  80.  
  81. Since time was running short, we decided to review our earlier ideas about
  82. the kinds of applications we wanted to support and the implications they
  83. have on the protocol.  We decided to do this my E-mail.  Phil will
  84. redistribute his messages entitled "Connection Oriented Protocol" and
  85. "Application Characterization" and Claudio will redistribute the minutes of
  86. the October 88 meeting.  We will all read the first three sections of Guru's
  87. paper "The Next Generation of Internetworking".  We will continue this
  88. discussion by E-mail.  Phil and Guru will be in charge of writing a
  89. resulting paper.
  90.  
  91. ST_protocol_specification_meeting_of_26_July_1989___
  92.  
  93. We went over the decisions we had made at the previous meeting and made a
  94. number of new decisions.
  95.  
  96. Reviewing the agreements from the evening meeting on ST at Cocoa Beach in
  97. April:
  98.  
  99.  
  100.  
  101.                                         3
  102. o IP encapsulation:  adopt Steve Casner's description.
  103.  
  104. o Using IP-like headers:  tabled for now; this can be retrofitted later.
  105. o Interface to next higher protocol:  it is OK to make changes as long as
  106.  
  107.   there is a good reason for them.
  108.  
  109. o We will need to write more documents than this one.
  110.  
  111. o Control messages:  it is OK to define new ones if they have different
  112.   functions from the old ones.
  113.  
  114. o ST.DG: eliminated.
  115.  
  116. o Source route option:  it can be an option in the connect message.  For
  117.   multipoint this might be too hard, but one could at least do
  118.   incremental connections with a source route option on each.
  119.  
  120. o Security:  use SDNS.
  121.  
  122.  
  123.  
  124.                                      4
  125. New decisions to be made:
  126.  
  127.  
  128.    o Aggregation:  we just get rid of it.
  129.    o Routing:  the routing protocol is separate, just as for IP.
  130.  
  131.    o Next protocol field:  should this just be part of the Extension field
  132.      (EXT= PROTOCOL & PORT)? But should ST carry only the IP address and
  133.      protocol field, as does IP, and let the higher-level protocol carry the
  134.      port number, as does TCP? This assumes that the "open" message of the
  135.      higher-level protocol is carried in the ST connect message.  Then, in
  136.      multipoint the ST header must have a list of addresses and NVP must
  137.      have a list of ports.  We have not answered how the elements of these
  138.      two lists are associated nor decided this issue yet.
  139.  
  140.    o Keep PTP, or have a flag for automatic establishment of a reverse
  141.      connection?  Really, there should be three flags:
  142.  
  143.        1. "Don't assign a group address, I promise not to have more than 2
  144.           parties in the connection."
  145.  
  146.        2. "Do reverse HID assignment because there are only 2 parties now."
  147.  
  148.        3. "Allocate bandwidth for the reverse path, i.e., automatically set
  149.           up two connections at once.  For multipoint, set up N-1 individual
  150.           reverse connections." Would have to carry two flowspecs in the
  151.           connect.
  152.  
  153.      An issue is that multiple connection names must be assigned.  If the
  154.      source does them all, then the connection name could wind up
  155.      corresponding to (having the IP address of) a host that's no longer in
  156.      the connection:
  157.  
  158.           Step 1.     Host A opens a multipoint connection to hosts B and
  159.                       C with the reverse bit on.  This creates
  160.                       connections named A1(A -> B,C), A2(B -> A), and A3
  161.                       (C -> A).
  162.  
  163.           Step 2.     Host C incrementally adds to connection A3 a path
  164.                       to host D, so we have A3 that connects C->A,D.
  165.  
  166.           Step 3.     Host A drops out, leaving A3 as a connection from C
  167.                       to D (but the connection name includes A).
  168.  
  169.      Is this a killer?  "A detail for the RFC writer to work out."
  170.  
  171.    o HID negotiation:  Claudio will write up a reasonable one from his
  172.      proposals for review, and we will use the static assignment subset
  173.      implementation in practice.
  174.  
  175.    o Robustness measures:  We need more link-state information exchange to
  176.  
  177.  
  178.  
  179.                                         5
  180.      determine if ST connectivity is still established.  That is, we must be
  181.      able to tell if ST state was lost at the next agent.  If there's a
  182.  
  183.      temporary net outage but no state loss, then just try a network repair
  184.      (reallocate stream in WBnet).  If a link goes down long enough to
  185.      declare it dead, then back up hop by hop to do a pruned, depth-first
  186.      search for alternate connection paths.  The pruning is based on
  187.      whatever routing information is available, so paths that are known to
  188.      be insufficient are not tried.  We will use Claudio's BREAK proposal
  189.      for repairing the connection.
  190.  
  191.  
  192. ST_protocol_specification_meeting_of_27_July_1989___
  193.  
  194. Continuing the previous day's discussion:
  195.  
  196.  
  197.      Robustness-level timeouts to keep track of agents going down:
  198.      Exchange of keepalive control packets is per ST agent pair, which
  199.      means per IP address pair.  This only goes on if there is a
  200.      connection up.  An implementation may choose not to timeout if
  201.      data is flowing but keepalives don't come in (fall behind).  May
  202.      want to have a separate timeout for each connection that is
  203.      determined by the application:  the connection is not flushed
  204.      immediately upon declaring the link down, but only when the
  205.      timeout expires after that (timeout may be zero).  Applications
  206.      should/may have their own data-dependent timeout, and then
  207.      disconnect on failure.
  208.